Speed up LinearQubitOperator matvec - #1417

…ransform (quantumlib#1427)

Third of the operator hot-path findings from quantumlib#1407; the earlier two are
quantumlib#1415 and quantumlib#1417.

`jordan_wigner` on an `InteractionOperator` maps the one- and two-body
integrals
straight to Pauli terms instead of going through a `FermionOperator`
first, and
quantumlib#587 points at exactly this routine as the fast path to build on ("there
is a
special routine that maps the InteractionOperators directly to qubits
... and
that is faster"). quantumlib#121 is the other side of it: it flagged this same
routine as
"surprisingly slow" back in 2017 and got closed without a fix.

The transform walks every one-body pair and every pair of pairs, so the
two-body
part is O(N^4). For each Pauli string it built a fresh single-term
`QubitOperator` and summed that into the running total. Each of those
constructions parses the term, validates every `(index, action)` factor,
runs the
Pauli `_simplify`, and in the three-unique-index case multiplies by a
`Z`
operator, which deepcopies. None of that is needed to add a term to a
sum: a
`QubitOperator`'s `terms` is just a dict from a sorted tuple of `(index,
action)`
factors to a coefficient, and the strings this routine emits are already
sorted
with their factors already combined, so there is nothing for the
constructor to
normalize.

This accumulates the `pauli_string -> coefficient` pairs into a plain
dict with a
small `_add_term` helper that does what `__iadd__` / `__isub__` do to a
single
term (add onto the running value, drop it once it falls under
`EQ_TOLERANCE`), and
builds one `QubitOperator` at the end by assigning the finished dict to
`.terms`.
Accumulating into a dict instead of building and summing single-term
operators
avoids that per-term construction and validation, and it measures about
2x
faster, with identical output.

### Public functions

`jordan_wigner_one_body` and `jordan_wigner_two_body` are public and
re-exported,
and `bksf_test` and `jordan_wigner_test` call them directly, so they
keep their
signatures and their output. I pulled the term-building logic into two
private
helpers (`_one_body_terms`, `_two_body_terms`) that return the dict, and
the
public functions and the interaction-op driver both go through them, so
there is
one copy of the logic and the public results are unchanged. The `Z`
times
hopping-term product in the three-unique case is a single-qubit
relabeling (the
shared qubit carries at most a parity `Z`, and `Z` squared is the
identity), so it
is a direct toggle of that index in the string now rather than an
operator
multiply and deepcopy.

### Correctness

Before editing the source I captured the current `jordan_wigner` output
on 104
random real `InteractionOperator`s and saved it. The mix is physical
(symmetric, molecular-style) operators, dense generic real tensors,
sparse and
very sparse tensors, one-body-only, constant-only, and the exact-zero
operator,
at N = 1, 2, 3, 4, 6, 8, 10, 12. The new code reproduces that captured
output
exactly on every case: identical term-key sets, max absolute coefficient
difference 0, and `(new - old).induced_norm(1)` equal to 0. It also
matches an
independent dict-based reference I wrote separately, to the same 0.
Seeds are
fixed, so the check is deterministic.

`jordan_wigner_test.py` and `bksf_test.py` pass (the two public helpers
are
checked there against the `FermionOperator` path over a full index grid
with
complex coefficients), and `transforms/` passes as a whole. black and
mypy are
clean on the file. Every changed line is hit by the existing suite
except the
pre-existing `n_qubits < count_qubits(iop)` guard, which the old code
did not
cover either and which I left untouched.

The routine is still documented as real-only and this does not change
that. It
computes the same coefficients from the same integrals; only the
container they
land in changed.

### Benchmarks

Random real InteractionOperators, cumulative `jordan_wigner` time.
Medians over 5
repeats within each of 6 alternated upstream/branch rounds, fixed seeds,
on an
Intel Core Ultra 5 225 laptop (Windows, Python 3.12, numpy 2.5).

    N     upstream    ours       speedup
    8     16 ms       7.6 ms     2.1x
    12    101 ms      48 ms      2.1x
    16    359 ms      177 ms     2.0x
    20    963 ms      476 ms     2.0x
    24    2222 ms     1093 ms    2.0x